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Abstract 

JCPenney  must  operate  a  highly  reliable,  flexible,  and  cost  effective  computing  and  networking 
environment  in  order  to  support  the  needs  of  its  1,250  retail  stores  and  catalogue  sales  business.  This 
case  study  describes  the  operations  infrastructure  that  the  firm  has  developed  in  order  to  address 
these  requirements.  JCPenney  is  attempting  to  develop  a  single  network  and  systems  management 
process  for  its  mainframe  and  client-server  environments.  IT  management  has  articulated  a  clear 
architecture  for  accomplishing  a  seamless  operating  environment  that  centralizes  and  automates  as 
much  of  the  operations  work  as  possible.  The  case  is  intended  to  help  readers  understand  the 
complexities  of  current  network  and  systems  management,  and  identify  issues  important  to  the 
development  of  reliable,  cost  effective,  and  secure  computing  operations. 

This  is  one  in  a  series  of  case  studies  developed  for  MIT's  executive  education  course  on  "Managing 
the  IT  Network  for  Global  Competitiveness.  "  The  case  study  and  accompanying  teaching  note  are 
intended  to  describe  and  analyze  one  company's  experiences  in  building  and  managing  its  IT 
infrastructure. 
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Introduction 

Committed  to  an  information  technology  architecture  that  would  provide  better  customer  service  and 
more  accurate  data  capture,  JCPenney  started  moving  to  a  TCP/IP  networlc  environment  in  early 
1993.  By  late  1995,  most  major  transaction  systems  still  ran  in  an  SNA  environment,  but  the  TCP/IP 
network  was  in  use  at  all  major  Penney's  locations.  Dave  Evans,  CIO,  noted  that  the  new 
environment  offered  new  opportunities  for  IT  applications,  but  it  also  presented  new  challenges: 

All  the  skills,  the  diagnostics,  the  capacity  planning,  the  trouble-shooting,  the 
software  distribution,  the  things  that  we  really  knew  how  to  do  very 
efficiently,  we're  now  relearning  how  to  do  in  this  new  environment.  So,  I 
guess  we're  catching  all  of  the  childhood  diseases  that  come  with  this  new 
environment,  and  it's  not  as  smooth  nor  is  it  as  efficient  from  an  operational 
point  of  view  as  the  one  that  we've  been  tuning  up  for  20  years. 

Evans  believed  that  network  and  systems  management  were  critical  to  delivering  on  promises  that 
his  area  made  to  business  unit  managers.  He  relied  on  John  Dratch's  Data  Processing  and 
Technology  Support  Group  to  design  and  implement  an  operations  support  architecture  that  provided 
cost-effective,  reliable  computing  for  all  the  company's  mainframe  and  distributed  processing. 

Background 

In  1913,  nine  years  after  James  C.  Penney  had  opened  his  first  store,  his  company  adopted  the 
Penney  Idea.  This  statement  (see  Exhibit  1)  defined  JCPenney' s  commitment  to  the  well-being  of 
its  customers  and  employees.  By  1995,  the  company  owned  and  operated  1,250  retail  stores  in  the 
U.S.  and  Latin  America,  but  the  Penny  Idea  continued  to  define  its  key  values. 

JCPenney,  which  specialized  in  men's,  women's,  and  children's  clothing,  and  home  furnishings,  had 
sales  in  1995  of  over  $21  billion,  including  $3.8  billion  in  catalogue  sales.  Sales  and  Catalog  were 
the  two  largest  of  Penney's  eleven  business  divisions,  which  included  a  drug  store  operation,  life 
insurance  and  a  large  credit  organization.  Penney's  employed  200,000  associates,  the  majority  of 
whom  were  part-time  sales  associates. 

Despite  spending  less  than  the  industry  average  on  IT,  JCPenney  had  traditionally  been  a  technology 
leader  in  its  industry,  and  Penney's  associates  had  come  to  depend  on  technology  for  business 
solutions.  For  example,  Penney's  was  a  heavy  user  of  EDI,  exchanging  over  95  million  electronic 
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documents  in  1995,  and  Penney's  buyers  around  the  world  had  on-line  access  to  management 
information  and  design  graphics.  Evans  attributed  the  technology  leadership  to  a  series  of  top 
management  teams  that  recognized  the  importance  of  IT: 

We've  been  lucky  in  that  every  chairman  we've  had  for  the  last  thirty  years 
has  been  a  great  promoter  of  technology,  going  back  to  Milt  Batten,  who  was 
in  the  '60s,  when  we  were  first  learning  how  to  do  point-of-sale.  We've  only 
had  four  chairmen  in  that  time,  but  every  one  of  them  has  believed  that  you 
have  to  invest  in  these  things,  keep  up-to-date,  take  a  leading  position  in  the 
industry.  That  sets  an  atmosphere  for  acceptance,  which  is  certainly  better 
now  than  it  was  thirty  years  ago.  I  like  to  say  now  that  people  think  of 
systems  as  something  we  do  for  them;  they  used  to  think  of  it  as  something 
we  did  to  them. 

Evans  noted  that  the  migration  to  newer  technologies  was  expensive.  It  took  both  top  management 
commitment  and  the  availability  of  financial  resources  to  make  it  happen: 

We've  had  a  major  period  of  technical  transformation  since  1987-88.  During  that 
time,  we've  had  a  very  strong  balance  sheet.  When  many  of  our  competitors  were 
in  bankruptcy  court,  we  were  in  TCP/IP  class.  We  were  able  to  invest  consistently 
through  this  period,  right  through  a  recession  in  1991  and  1992,  with  hardly  any 
slowdown.  A  strong  balance  sheet  is  really  one  of  the  things  that  enabled  this  rather 
rapid  transformation  of  a  pretty  large  network. 


Information  Systems  at  JCP 

JCP  had  a  highly  centralized  information  systems  organization.  With  computing  capabilities 
encompassing  60,000  POS  terminals  and  100,000  other  electronk  terminals  in  4,000  different 
physical  locations  around  the  world,  responsibility  for  the  firm's  2,500  mainframe  Mips,  10 
terrabytes  of  storage,  1000  servers,  48  Tandem  Cyclone  processors,  and  six  AS/400  specialty  retail 
systems  was  all  centralized  under  Evans.  IS  had  five  units  (see  Exhibit  2).  Two  units.  Personnel  and 
Security,  and  Accounting  and  Control,  were  small  staff  units.  Systems  Development  was  staffed 
by  600  applications  programmers  who  developed  business  systems.  Communications  provisioned 
lines  for  voice  and  data  communications.  Data  Processing  and  Technology  Support,  which  was 
headed  by  John  Dratch,  was  responsible  for  infrastructure  development,  deployment,  operations  and 
support. 

Data  Processing  and  Technology  Support  totaling  500  associates  was  comprised  of  seven  subunits, 
the  largest  of  which  was  the  Operations  organization.  This  subunit  operated  and  managed  the 
computing  and  technology  infrastructure  for  the  entire  company.  The  Technology  Support 
organization  was  responsible  for  asset  management,  equipment  evaluation,  capacity  planning, 
software  distribution,  and  troubleshooting  and  an  Advanced  Technology  Group  studied  emerging 
technologies  and  their  applicability  to  JCPenney.  A  small  Strategic  Planning  group  studied 
functional  requirements  within  IS  and  examined  and  recommended  hardware  and  software 
technologies  which  would  improve  effectiveness  and  efficiency  of  the  data  processing  technology 
operation  and  infrastructure.  The  Root  Cause  Analysis  Team  identified  and  attacked  the  root  causes 


of  recurring  problems.  An  Operational  Support  Team  focused  on  procedures,  audits,  and  disaster 
planning  and  recovery.  The  Quality  and  Customer  Services  unit  spearheaded  continuous 
improvement  for  the  organization  and  customer  liaison  activities  to  insure  quality  services  were 
provided. 

The  migration  from  SNA  to  TCP/IP  and  the  increasing  use  of  departmental  servers  presented  a 
complex  management  environment.  Contributing  to  the  complexity  was  the  need  to  convert  token 
ring  to  ethernet,  prepare  for  frame  relay  and  ATM,  and  sort  out  confusion  among  competing 
relational  data  base  technologies  (DB2,  Oracle,  Informix,  Sybase).  At  the  same  time,  the  user 
community  had  developed  higher  expectations  for  functionality  and  greater  interest  in  handing  over 
responsibility  for  their  technology  to  the  IS  unit. 

Dratch  noted  the  potential  for  the  complexity  to  lead  to  climbing  headcounts  and  inefficient 
operations.  To  provide  cost  effective  operations  and  support,  he  established  a  vision  for  a  seamless 
operation  in  a  multi-platform  environment: 

We  said  to  ourselves  that  what  we  really  need  to  do  is  create  an 
environment  in  the  Penney  Company  that  enables  us  to  embrace  all  the 
different  platforms  and  the  technologies  in  a  disciplined  way  as  if  it  was  a 
single  logical  production  environment  —  very  efficient,  well  run,  well 
disciplined. 

To  enable  this  vision,  Penney's  consolidated  operations  at  its  four  data  centers  into  a  single 
command  center  in  Dallas,  called  the  Information  Technology  Control  Center  (ITCC).  Staff  in  the 
rrCC  manned  the  help  desk  and  controlled  lights-out  operations  in  the  Reno,  Kansas,  and  Columbus 
data  centers,  which  handled  most  mainframe  processing.  These  three  data  centers,  as  well  as  a  data 
center  in  Dallas  that  was  used  primarily  for  test  and  development,  received  messages  and  alerts  from 
each  other,  so  they  could  provide  backup  as  needed.  The  ITCC  was  at  the  heart  of  Dratch's  plans  to 
develop  a  single  set  of  processes  and  procedures  for  computer  and  network  operations  and  support 
at  JCPenney,  using  its  foundation  rules-based  automation  systems. 


The  Information  Technology  Control  Center  (ITCC) 

Reminiscent  of  NASA's  command  center  in  Houston,  the  ITCC  was  located  in  a  large  room  in  which 
staff  occupied  seven  long  rows  of  workstation-equipped  furniture,  all  facing  four  large  screens  that 
highlighted  the  status  of  key  systems  and  components.  (Exhibit  3  depicts  the  role  of  the  ITCC.) 
Distributed  hardware  and  software  were  monitored  by  rules-based  automation  management  systems 
that  generated  alerts  and  messages  when  they  did  not  function  to  specification.  The  rules-based 
management  systems  either  automatically  provided  a  resolution  or  forwarded  messages  and  alerts 
to  ITCC  staff  members  who  diagnosed  problems  and  issued  commands  to  resolve  them.  At  the  same 
time  support  people  captured  data  on  volume  and  bottlenecks.  They  provided  real  time  resolutions 
and  adjustments  through  performance  tuning  parameters;  the  data  were  then  passed  on  to  capacity 
planners  for  problem  analysis  and  capacity  projection  updates.  ITCC  staff  also  interfaced  with 
application  developers,  vendors,  and  customers,  any  of  whom  might  provide  changes  or  requests  for 
help.  A  key  role  of  the  ITCC  was  to  integrate  the  requirements  and  changes  arising  from  each  of  the 
three  sources:  the  hardware  and  software,  the  support  teams,  and  the  applications  developers. 
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rrCC  responsibilities  were  addressed  by  four  different  kinds  of  technicians.  The  first  two  rows  of 
operators  were  dedicated  to  help  desk  operations.  Help  desk  staff  received  calls  through  a 
communications  front  end  that  captured  the  calling  number  and  checked  it  against  a  database  to 
identify  the  caller.  It  then  displayed  his  or  her  technology  configuration  on  the  operator's  terminal. 
When  the  caller  reported  a  problem,  the  help  desk  operator  opened  an  incident  report  that  was 
recorded  in  the  InfoSys  database.  For  a  narrow  range  of  problems,  help  desk  operators  could  make 
the  fix.  Typically,  they  channeled  problems  to  one  of  four  or  five  sources,  based  on  whether  they 
appeared  to  be  computer  problems,  network  problems,  or  programming  problems.  When  technicians 
fixed  problems,  help  desk  operators  followed  up  with  callers  to  check  that  everything  was  working 
properly. 

The  third  row  in  the  ITCC  was  responsible  for  problems  reported  automatically  by  the  automation 
management  system.  Personnel  in  this  row  functioned  like  systems  operators  in  a  traditional  console 
environment.  They  were  primarily  responsible  for  determining  the  source  of  problems  and 
channeling  them  to  appropriate  problem  solvers  when  they  could  not  be  resolved. 

Problem  solvers  occupied  the  next  three  rows  in  the  ITCC.  They  attempted  to  restore  service  when 
there  were  network  or  computer  problems.  When  they  could  not  solve  problems,  they  would  escalate 
them  to  agent  specialists  in  other  units,  such  as  the  hardware  and  network  vendors  or  a  team  of 
advanced  information  technology  specialists.  They  would  record  any  action  they  took  in  the  same 
InfoSys  database  that  help  desk  operators  used  when  the  problem  was  reported. 

The  ITCC  received  approximately  54,000  help  desk  calls  each  month  and  opened  36,500  incident 
reports  (IRs).  The  IR  database  provided  data  on  the  kinds  of  errors  that  were  causing  failures  and  IS 
used  the  data  to  identify  common  cause  areas  needing  work.  They  also  tracked  statistics  so  that  they 
could  measure  their  improvement  in  reducing  the  number  of  IRs.  IS  distributed  monthly  status 
reports  to  business  unit  heads  that  indicated  the  number  and  percentage  of  IRs  that  affected  their 
-business  unit.  These  reports  fueled  discussions  of  systems  development  priorities. 

The  ITCC  operated  24  hours  a  day,  7  days  a  week.  Staff  in  the  ITCC  worked  twelve-hour  day  or 
night  shifts  alternating  between  three  and  four  days  a  week.  The  help  desk  operator  was  an  entry 
level  position.  With  training  and  experience,  individuals  could  progress  from  this  position  to  console 
operators  and  then  problem  solvers.  Some  then  moved  into  technical  roles  outside  the  ITCC. 

John  Dratch  believed  that  a  single  management  system,  that  integrated  across  technology  platforms, 
was  essential  to  the  efficiency  and  effectiveness  of  the  ITCC.  Six  disciplines —  Capacity  Planning, 
Change  Control,  Scheduling,  Automation,  Problem  Management,  and  Network 
Management — operationalized  the  single  system  concept.  These  six  disciplines  defined  the  key  IS 
operations  and  support  activities  that  were  captured  in  the  model  in  Exhibit  3.  Capacity  planning  was 
a  support  unit  initiative.  Scheduling  and  automation  activities  emanated  from  the  hardware  and 
software.  And  the  interface  constituencies  (developers,  users/customers,  and  vendors)  initiated 
change  control  and  problem  management.  Network  management  activities  could  arise  from  any  of 
the  three  endpoints. 
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Capacity  Planning 

Capacity  planning  was  an  important  discipline  because  growing  ad  hoc  use  of  query-based 
applications  and  communications  capabilities  led  to  more  volatile  patterns  of  resource  utilization, 
while  the  dispersion  of  processing  power  presented  increasing  numbers  of  devices  where  bottlenecks 
could  occur.  Technical  support  staff  responded  to  this  challenge  by  collecting  detailed  information 
about  system  use  that  allowed  them  to  track  trends. 

Key  to  the  planning  effort  were  the  annual  forecasts  of  prime  business  units  from  the  eleven 
Penney's  divisions.  Prime  business  units  represented  the  drivers  of  computer  activity  in  each 
division.  For  example,  in  payroll,  headcount  was  a  prime  business  unit;  in  catalogue,  a  prime 
business  unit  would  be  number  of  orders  written  or  dollars  of  demand.  In  order  to  use  this 
information  for  forecasting,  each  computing  platform  kept  a  running  history  of  resource  utilization 
for  jobs  that  ran  on  it.  This  allowed  IT  to  convert  prime  business  units  into  resources  consumed  and 
to  track  trends  over  time.  Modeling  systems  from  BGS,  Best/1,  Capture,  and  Visualizer  Tools 
estimated  processing  requirements,  while  tools  from  BGS,  Legent,  and  Sterling  estimated  storage 
requirements. 

Change  Control 

JCPenney  instituted  about  100,000  changes  a  year  in  the  form  of  changes  to  existing  systems, 
implementation  of  new  systems,  installation  of  new  hardware  or  software,  changes  in  the 
environment,  or  shutdowns.  These  changes  could  come  from  any  one  of  34  identified  change  agent 
groups — ranging  from  the  company's  600  applications  programmers  to  external  hardware  and 
software  vendors.  To  ensure  that  a  change  proposed  by  one  change  agent  would  not  conflict  with  the 
operations  or  change  initiative  of  another  agent,  all  change  agents  input  the  proposed  changes  into 
the  online  control  system,  indicating  the  nature  of  the  change  and  when  they  would  like  it  to  occur. 
Associates  responsible  for  change  control  checked  for  incompatibilities  and  conflicts  and  either 
accepted  or  rejected  each  change.  Accepted  changes  were  released  into  the  system  and  would 
•  automatically  be  executed  as  scheduled.  Rejected  changes  were  returned  through  the  system  to  the 
originator  with  an  explanation  of  the  conflict  they  would  cause.  They  could  be  restaged  on  a  different 
schedule.  The  change  management  system  automatically  notified  originators  when  changes  had  taken 
place. 

The  change  management  system  was  homegrown  and  produced  an  audit  trail  that  allowed  IT 
management  to  refer  to  recent  changes  when  analyzing  system  failures.  Physical  changes,  such  as 
a  new  CPU,  power  system,  or  UPS,  were  manually  input  into  the  change  system  to  provide  a 
complete  audit  trail,  which  focused  attention  on  likely  causes  for  unexpected  crashes  or  processing 
problems.  The  system  also  provided  security  for  corporate  assets  by  separating  creation  from 
installation  of  all  changes. 

Scheduling 

JCP  ran  approximately  15  million  jobs  a  year  according  to  a  thousand  unique  schedules.  Although 
these  jobs  increasingly  ran  on  dispersed  processors,  JCPenney  attempted  to  keep  scheduling 
centralized  to  better  control  the  scheduling  function  and  more  easily  respond  to  the  need  to  revise 
schedules  due  to  hardware  and  software  problems.  ESP,  a  scheduling  package  from  Cybermation, 
allowed  the  Operations  group  to  automate  99.4%  of  the  firm's  job  scheduling  by  specifying  times 
and  rules  for  running  batches.  ESP  ran  jobs  based  on  time  requirements  and  prespecified 


dependencies  between  jobs.  It  detected  failures  and  reported  system  crashes  caused  by  applications 
code  to  the  automation  system. 

Automation 

The  computers  at  JCPenney  generated  2.5  million  daily  alerts  and  messages  on  the  status  of  jobs  they 
ran.  To  most  efficiently  identify  those  messages  that  required  human  intervention,  Penney's  Data 
Processing  and  Tech  Support  group  attempted  to  automate  as  many  of  the  responses  as  possible  and 
to  notify  operators  of  the  need  for  their  services  through  exception  reporting. 

Automation  was  rules  based.  Whenever  the  computer  put  out  an  alert  or  message,  the  automation 
system  referred  to  a  customized  data  base  that  specified  the  action  that  should  be  executed.  When 
the  system  was  installed  in  1993,  it  handled  93-94%  of  all  messages.  By  late  1995  it  provided 
automatic  responses  to  97%  of  the  2.5  million  daily  alerts.  The  approximately  75,000  alerts  and 
messages  for  which  there  was  no  match  on  the  database  required  manual  interaction  with  automation 
staff  who  continued  to  add  solutions  to  the  database. 

ESP  could  identify  problems  that  resulted  from  poor  applications  code.  In  those  cases,  the 
automation  system  referred  to  a  table  of  beeper  numbers  which  were  associated  with  each  application 
job.  If  a  job  failed,  it  was  the  responsibility  of  the  person  with  the  beeper  to  resolve  it.  Beepers  were 
passed  around  so  that  all  applications  were  covered  at  all  times.  The  beeper  put  out  250  characters 
on  the  nature  of  the  problem  so  that  the  responsible  individual  could  determine  its  urgency. 

The  automation  capability  was  provided  by  Legent's  Automate  family  of  products.  It  was  platform- 
based,  so  that  messages  coming  from  any  platform  could  be  handled  at  the  source.  Rules  databases 
for  each  platform  provided  the  logic  for  resolving  most  problems  automatically.  When  a  failure  was 
detected,  the  management  system  activated  the  centralized  problem  management  system  and  opened 
an  incident  report.  The  system  operators  in  the  third  row  of  the  ITCC  responded  to  these  exceptions. 

Automated  Problem  Management 

A  key  concern  of  IS  management  was  the  ability  to  provide  fast,  competent  support  to  IT  users 
throughout  the  firm.  JCPenney' s  help  desk  received  350,000  calls  per  year  and  IS  focused  on 
processes  that  would  help  it  quickly  escalate  all  problems  to  someone  who  could  resolve  them.  The 
key  to  the  automated  problem  management  system  was  an  InfoSys  database  that  tracked  each  call 
from  the  time  it  was  received,  through  all  attempts  to  resolve  it,  to  its  eventual  resolution  and  sign- 
off  by  the  caller. 

While  computer-reported  problems  automatically  opened  an  incident  report,  help  desk  staff  opened 
incident  reports  generated  by  user  calls.  These  incident  reports  were  held  in  the  InfoSys  database, 
which  both  inventoried  outstanding  problems  and  provided  the  human  interface  for  individuals  who 
needed  to  know  the  nature  or  status  of  a  problem,  and  the  kinds  of  action  that  had  been  taken  on  it. 
Help  desk  staff  escalated  problems  to  appropriate  ITCC  technicians  who  solved  the  problem  or, 
when  they  could  not,  prepared  work  lists  for  technical  specialists  who  could  fix  them.  The  technical 
specialists  updated  the  database  as  they  worked  on  problems.  The  system  could  then  fax  out  status 
reports  in  response  to  inquiries  on  open  problems. 


Network  Management 

The  network  management  system  was  the  toughest  component  to  tie  into  the  automated  problem 
management  system.  JCPenney  had  been  moving  to  a  TCP/IP  architecture,  but  approximately  80% 
of  its  environment  was  still  managed  by  SNA.  In  1995  no  single  network  management  product 
managed  both  the  mainframe  and  distributed  environments.  Thus,  the  firm  relied  upon  multiple 
Element  Management  Systems  (EMSs)  to  manage  various  networking  technologies.  The  EMSs 
employed  included:  NetView  to  manage  SNA,  OpenView  to  manage  TCP/IP,  TNM-6000  to  manage 
IDNX  circuits,  ComSphere  6800  to  manage  DSUs,  and  the  Paradyne  5530  Analysis  System  to 
manage  analog  modems.  It  was  developing  code  internally  to  create  a  single  source  for  all  network 
alerts. 

In  addition  to  merging  the  management  systems  for  the  major  computing  environments,  network 
management  involved  monitoring  and  troubleshooting  all  the  devices  on  the  network.  Traditionally, 
each  major  kind  of  device  had  its  own  management  system.  For  example,  Penney's  used  Paradyne 
to  manage  its  modems.  It  had  separate  management  systems  to  manage  devices  like  routers  and 
DSUs.  The  challenge  presented  by  the  management  systems  for  the  individual  devices  was  that  each 
management  system  tended  to  monitor  the  entire  network.  As  a  result,  tying  them  into  the 
automation  system  in  addition  to  NetView  and  OpenView  generated  multiple  alarms  when 
something  went  wrong: 

You  could  have  a  modem  down  here,  so  the  line  it's  connected  to  doesn't 
work  because  the  modem  is  broken  and  the  device  on  the  other  end  of  the  line 
doesn't  work  because  the  line  isn't  working.  Is  it  the  modem  that's  broken  or 
the  line  that's  broken  or  the  device  that's  broken?  You  get  three  alerts  coming 
up.  So  which  one  do  you  chase?  (John  Dratch) 

Bob  Andrzejewski,  Project  Manager  in  Communication  Support,  explained  the  limitations  of  current 
networlt  support: 

When  a  router  goes  down  out  in  the  network,  we  want  to  capture  that  alarm, 
do  some  automation,  forward  that  alarm,  and  get  an  incident  report  (IR)  out 
in  front  of  the  problem  solver.  We  can  do  that,  but  we  open  up  too  many  IRs. 

Andrzejewski  noted  that  generating  multiple  IRs  for  a  single  problem  meant  that  excess 
resources  were  applied  to  troubleshooting: 

It  becomes  very  labor-intensive.  If  you  open  50  IRs,  you  could  have  50 
people  working  on  the  same  problem.  An  event  correlation  engine  was 
required. 

Increasing  automation  of  network  management  required  end-to-end  connectivity.  Consequently, 
Andrzejewski's  team  was  developing  a  configuration  database  that  would  map  all  network 
components  and  sort  through  multiple  alerts  to  determine  the  source  of  a  problem.  A  fully  developed 
configuration  management  system  interacting  with  the  automatic  problem  management  system 
would  eventually  enable  very  efficient  network  management.  The  configuration  management  system 
would  identify  which  device  was  most  likely  at  fault  when  multiple  alerts  were  generated.  Then  the 


automatic  problem  management  system  would  check  a  rules  database  that  dictated  how  it  should  be 
resolved — whether  that  solution  was  automated  or  manual. 

Developing  the  configuration  database  was  a  time-consuming  effort  that  started  with  identifying  the 
location  of  all  network  components.  This  information  existed  in  various  places  in  JCPenney,  such 
as  with  the  Communications  unit  or  at  the  individual  stores.  Collecting  the  information  from  these 
sources  for  purposes  of  developing  a  single  database  required  changes  in  how  individuals  collected 
and  accessed  information  that  was  important  to  them,  so  Andrzejewski's  team  would  need  to  sell 
each  individual  on  the  value  of  the  database.  Once  the  data  were  collected,  the  team  would  need  to 
understand  and  capture  the  relationships  among  the  components  in  the  database.  They  would  also 
need  to  develop  methods  for  constantly  updating  the  database. 

While  waiting  for  the  configuration  database  to  support  increased  automation  of  network 
management,  ITCC  staff  could  use  graphical  maps  to  help  them  monitor  the  networks.  The  maps 
highlighted  the  parts  of  their  networks  that  were  out  of  commission,  which  could  visually  help  locate 
the  source  of  a  problem,  but  they  could  not  pinpoint  specific  problems  and  solutions: 

And  the  question  is,  do  you  want  to  give  the  technicians  too  much 
information  that  they  have  to  sort  through  so  you  can  service  the  customer 
now,  or  do  you  want  to  wait  until  you  get  the  Cadillac  solution  and  you're 
stuck  with  people  calling  in  and  saying,  "Hey,  something's  wrong!"  when 
you  could  have  known  about  it?  It's  a  real  quandary.  Do  you  flood  the 
technicians,  and  get  the  problem  now,  or  do  you  wait  and  have  them  call  you? 
(John  Dratch) 


Quality  Initiatives 

IS's  concern  with  continuous  improvement  of  operations  and  support  was  articulated  in  the  Data 
Processing  Quality  Initiative.  This  initiative  was  guided  by  five  quality  tenets  (and  accompanying 
measures):  assurance  (efficiency),  tangibles  (effectiveness),  reliability  (consistency),  responsive 
(responsiveness),  and  empathy  (satisfaction).  (The  tenets  and  measures  are  described  in  Exhibit  5.) 
The  five  measures  were  each  composites  of  many  individual  measures  (over  four  hundred  total 
measures  existed  in  early  1996)  that  had  been  automated  and  were  constantly  tracked  by  the  Data 
Processing  organization.  The  tracking  applied  principles  of  statistical  quality  control  and  charts  were 
available  via  an  intranet  to  all  Penney's  associates.  "Out  of  control"  measures  generated  electronic 
mail  messages  with  a  control  chart  to  the  owner  of  the  measure.  Several  procedures  associated  with 
the  development  of  the  ITCC  supported  JCPenney's  quality  initiative.  These  included  (1)  morning 
meetings  to  review  unresolved  technical  problems;  (2)  incident  report  tracking  and  database  mining; 
and  (3)  IS  customer  service  representatives. 

Morning  Meetings 

Every  morning  at  8:00  John  Dratch  met  with  his  management  team  and  their  direct  reports,  as  well 
as  vendors  and  internal  customers  to  do  a  twenty-four  hour  shift  turnover.  The  meeting  typically 
lasted  about  15  minutes  and  was  conducted  via  video  conferencing  to  include  associates  at 
headquarters  (which  included  the  ITCC)  and  specialists  in  the  Advanced  Information  Technology 
Group  based  at  the  data  center  in  a  different  part  of  Dallas.  The  discussion  focused  on  reviewing  the 

8 


prior  day's  action  items,  open  incident  reports  and  recurring  problems.  Each  day  participants 
clarified  responsibility  for  follow-up. 

A  summary  of  the  meetings  was  provided  on  both  e-mail  and  voice  mail  for  IS  managers  who  were 
not  present.  Dave  Evans,  the  CIO,  commented  on  the  usefulness  of  these  meetings: 

They  publish  a  report  every  day  on  e-mail  between  9:00  and  10:00  in  the 
morning.  I  look  at  it  and  usually  I  don't  do  anything  except  file  it,  but  I  might 
have  a  question  about  some  particular  item  and  I  can  shoot  off  a  question 
about  it.  The  operational  part  of  my  job  is  a  fairly  small  percentage,  but  I  do 
that  every  day. 


Incident  Report  Tracking 

The  InfoSys  database  provided  a  record  of  all  incident  reports  (IR).  IS  used  this  both  to  identify 
recurring  problems  and  to  measure  its  progress  in  reducing  the  number  of  technology  problems  over 
time.  A  one-page  .nonthly  summary  for  each  business  unit  identified  the  ERs  associated  with  their 
systems  or  called  in  by  their  users.  The  IRs  were  tallied  according  to  their  source:  batch,  operating 
environment,  or  user-reported,  and  totals  were  reported  for  the  entire  firm  as  well  as  for  the  specific 
business  unit  (see  Exhibit  4).  IS  and  business  unit  managers  could  use  these  tallies  to  identify 
systems  that  should  be  rewritten  and  users  who  needed  training  or  new  desktop  capabilities. 

75  Customer  Service  Representatives 

The  Data  Processing  and  Technology  Support  unit  had  six  customer  service  representatives  who 
worked  with  the  business  divisions  to  communicate  IT  capabilities  to  the  businesses  and  to  represent 
business  unit  needs  to  IT.  Their  roles  involved  a  great  deal  of  communicafion  with  the  goal  of 
increased  understanding  and  more  effective  development  and  use  of  IT  resources.  Dratch  described 
the  customer  service  role  as  follows: 

He  acts  on  the  customer's  behalf  for  any  kind  of  problem  or  service.  He'll 
work  through  the  applications  people  and  the  operating  people.  He  speaks  our 
language;  he  speaks  the  customer's  language. 


Outcomes  and  Next  Steps 

JCPenney's  automation  and  discipline  enabled  it  to  reduce  computing  costs  below  the  industry 
standard.  Most  of  the  savings  resulted  from  reducing  the  headcount  required  for  infrastructure 
support  from  800  to  500  associates,  which  resulted  in  an  annual  savings  of  $1 1.5  million.  By  late 
1995,  Dratch's  organization  had  eliminated  most  repetitive  tasks,  automated  action  on  97%  of  the 
2.5  million  messages  and  alerts  generated  each  day,  enabled  automatic  opening  of  incident  reports 
in  95%  of  the  cases,  and  improved  effectiveness  and  efficiency. 

New  network  technologies  and  initiatives  would  continue  to  challenge  the  operations  and  support 
teams.  For  example,  the  firm  was  expanding  its  access  to  Internet  technologies,  particularly  its  use 


of  intranets.  Dave  Evans  noted  that  the  initial  use  of  intranets  was  to  improve  communications  with 
the  stores: 

We  have  an  accounting  manual,  a  merchandizing  manual,  a  personnel 
manual,  a  security  manual.  And  when  we  finish  those  we  have  another  big 
audience — there  are  5,000  suppliers  out  there  and  a  stack  of  manuals  for 
things  like  EDI,  invoicing  instructions,  packaging  instructions,  stitching 
instructions... 

Evans  noted  that  Penney' s  would  have  at  least  three  different  webs:  one  for  associates,  one  for 
suppliers,  and  one  for  connections  with  customers.  The  webs  would  take  advantage  of  the  TCP/IP 
networking  capabilities  that  Penney's  had  installed,  while  introducing  new  security  and  management 
issues. 

Dratch's  organization  would  continue  to  move  toward  automated  support  by,  among  other  things, 
expanding  management  of  UNIX  and  NT  environments,  absorbing  new  processors  (e.g.,  SP2  and 
CMOS),  adding  management  of  AS400  and  VM,  and  upgrading  desktops  to  Windows  95.  They 
would  continue  to  work  toward  the  objective  of  a  single  management  system  in  order  to  minimize 
cost  and  maximize  quality  in  an  increasingly  complex  computing  environment: 

When  you  buy  OpenView,  put  it  on  the  table  and  let  it  handle  Openview,  and 
then  get  something  to  handle  MVS  and  it's  handling  just  MVS,  and 
something  for  AS400  supporting  just  AS400,  it  forces  too  many  systems.  Our 
solution  is  to  have  Openview  open  up  an  incident  report  in  a  common  system. 
So  it's  easy  for  us  to  change  our  products.  You've  got  a  scheduling  product, 
you've  got  a  capacity  planning  product,  you've  got  a  network  product,  you've 
got  an  InfoSys  product.  Every  one  of  those  can  move  on  their  own  because 
they  become  part  of  the  operating  management  system  which  all  platforms 
talk  to. 


11-25-96 
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Exhibit  1 


The  Penney  Idea 


To  serve  the  public  as  nearly  as  we  can  to  its  complete 
satisfaction. 

To  expect  for  the  service  we  render  a  fair  remuneration,  and  not 
all  the  profit  the  traffic  will  bear. 

To  do  all  in  our  power  to  pack  the  customer's  dollar  full  of 
value,  quality  and  satisfaction. 

To  continue  to  train  ourselves  and  our  associates  so  the  service 
we  give  will  be  more  and  more  intelligently  performed. 
To  improve  constantly  the  human  factor  in  our  business. 
To  reward  the  men  and  women  in  our  organization  through 
participation  in  what  the  business  produces. 

To  test  our  every  policy,  method  and  act  in  this  wise:  "Does  it 
square  with  what  is  right  and  just?" 

Adopted  1913 


Exhibit  2 


JCPenney  Information  Systems 
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Exhibit  3 


JCPenney  Systems  Support  Model 


APPLICATION  DEVELOPMENT  -  VENDORS  -  CUSTOMERS 


Exhibit  4 


Monthly  Incident  Report  Summary 
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Exhibit  5 


JCPenny  Quality  Initiative 


TENETS 


■Assurance  -  Assuring  ihal  we  have  the  resources 
and  skills  ti>  do  ihc  work.  This  instills  confidence  in 
cuch  of  us  and  our  tapabilily    Without  confidence 
you  cannot  have  trust. 


■Tangibles  -  To  expect  that  the  twils  and  processes 
we  operate  and  manage  are  of  the  highest  quality  and 
reliability 


■Reliability  -  The  ability  to  perform  promised, 
dependable  services-  Two  key  wonls  -  promised  and 
dependable  ■  relate  to  the  character  of  our  organization 
and  translate  mto  trust. 


■Responsive  -  The  willingness  to  provide  prompt 
services:  whether  it's  answering  the  phone,  responding 
to  a  message,  delivering  an  output,  fixing  a  problem,  or 
responding  to  a  customer  neeJ  ,,,  show  you  understand 
the  urgency  and  thai  you  will  help. 


■Empathy  ■  Making  the  customer  led  thai  they  arc 
number  one  We  must  make  them  feel  that  they  are 
individuals  through  the  individualized  att£niion  we 
deliver. 


MEASURES 


■EfTiciency  •  our  financial  performance  as 
compared  to  the  budget 


■EfTecbveness  -  aimponent  reliability. 


■Consistency  -  meeting  schedules 
dependably. 


[  ■Responsiveness  -  meeting  commitments 
and  being  rcspt)nsive. 


■Satisfaction  -  results  pnxJuced  and 
expectations  met 
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JCPenney:  Developing  Seamless  Operations  in  a  Multi-Platform  Environment 

Teaching  note 
Jeanne  Ross,  MIT  Center  for  Information  Systems  Research 

jross@mit.edu 

The  JCPenney  case  describes  the  infrastructure  that  the  firm  has  developed  in  order  to  efficiently  and 
effectively  manage  its  distributed  computing  environment.  The  firm  is  attempting  to  develop  a  single 
network  and  systems  management  process  for  its  mainframe  and  client-server  environments.  IT 
management  articulated  a  clear  architecture  for  accomplishing  this  goal  and  has  selected  products 
and  done  in-house  development  to  develop  the  necessary  tools  and  platforms.  The  case  is  intended 
to  help  readers  understand  the  complexities  of  current  network  and  systems  management  and  identify 
the  issues  they  must  address  in  order  to  establish  reliable,  cost  effective,  and  secure  computing 
operations. 

The  case  was  developed  for  an  executive  course  on  network  management.  It  will  also  be  useful  for 
undergraduate  and  graduate  information  technology  students.  Although  the  technical  detail, 
particularly  the  identification  of  specific  products,  is  greater  than  they  need,  they  should  find  it 
interesting  to  note  the  number  and  variety  of  products  required  to  manage  a  large-scale  computing 
environment. 

Recommended  Discussion  Questions 

1.  Describe  the  systems  and  network  management  function  at  JCP.  What  are  the  primary 
concerns? 

2.  JCPenney  has  a  highly  disciplined  operations  management  environment.  What  has  made  this 
possible?  How  appropriate  is  the  architecture  it  has  developed?  How  appropriate  would  it 
be  for  other  firms?  Discuss  key  choices  and  identify  alternatives. 

3.  Discuss  the  ITCC.  What  are  its  critical  success  factors?  What  alternative  designs  might  make 
sense? 

4.  JCP  has  invested  considerable  resources  in  operations  management.  It  is  unlikely  that  any 
of  the  related  expenditures  have  a  direct  impact  on  JCP  customers.  How  might  the  firm 
justify  this  investment? 


Class  Discussion 

I.  Overview  of  network  and  systems  management 

For  most  classes,  the  primary  discussion  of  the  case  will  focus  on  developing  an  understanding  of 
the  infrastructure  management  function  in  an  organization.  Note  that  the  case  lists  the  primary 
responsibilities  as  they  are  perceived  at  JCP:  capacity  planning,  change  control,  scheduling, 
automation  (systems  monitoring),  problem  management/trouble  shooting,  and  network  management. 
These  are  important  concerns  in  any  large-scale  computing  environment.  It  is  useful  to  have  students 
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list  why  each  is  important  and  what  kinds  of  problems  a  firm  could  encounter  if  the  responsibility 
is  not  performed  well.  A  list  might  note  the  following: 

Capacity  planning:  ensuring  that  enough  processing  power  and  network  bandwidth  is  available  as 
needed.  This  has  become  particularly  challenging  as  on-line  queries  become  a  bigger  part  of  a  firm's 
computing  and  as  Internet  and  World-Wide  Web  access  experience  exponential  growth.  Sufficient 
capacity  is  important  to  provide  acceptable  response  times.  As  prices  for  both  bandwidth  and 
processing  power  decrease,  firms  are  increasingly  inclined  to  plan  for  excess  capacity  as  protection 
against  shortages.  But  this  does  not  make  capacity  planning  easy.  Growth  in  the  use  of  computing 
and  communications  technologies  has  not  been  linear,  so  it  is  difficult  to  anticipate. 

Change  control:  Constant  additions,  deletions,  and  changes  to  a  firm's  computing  assets  make  it 
difficult  to  monitor  the  impacts  of  individual  actions  on  an  entire  system.  This  has  become  a 
particularly  messy  problem  as  firms  allow  remote  locations  to  manage  their  local  area  networks  but 
connect  the  LANs  to  the  firm's  wide  area  network,  where  local  changes  can  have  unforeseen 
consequences.  For  example,  an  improperly  assigned  internet  address  can  bring  down  an  entire  system 
in  a  remote  location.  Many  firms  address  these  issues  through  standard  operating  procedures. 
Penney' s  has  decided  to  attack  it  by  centralizing  control  and  limiting  access. 

Scheduling:  Despite  the  growth  of  on-line  systems,  many  firms  still  run  large  numbers  of  batch  jobs. 
This  is  usually  automated  through  a  purchased  software  package,  as  described  in  the  case. 
Distributed  computing  environments  will  again  complicate  the  environment,  however,  if  jobs  are 
scheduled  locally  but  require  access  to  mainframe  data  or  processing  power. 

Automation  (systems  monitoring):  Automation  has  eliminated  the  tedious  work  of  the  systems 
operator  who  monitored  console  output  that  recorded  job  starts  and  ends.  Penney's  2.5  million  daily 
alerts  makes  it  easy  to  understand  why  automation  that  allows  management  by  exception  is  important 
to  management  efficiency.  It  is  also  easy  to  understand  why  JCP  is  attempting  to  reduce  the  number 
of  alerts  (currently  75,000  each  day)  that  require  personal  attention.  They  are  primarily  concerned 
with  identifying  failures,  but  they  need  to  automate  responses  to  all  other  alerts  to  ensure  that  all 
failures  are  identified. 

Automated  Problem  Management:  This  refers  to  the  electronic  database  and  related  processes  used 
to  support  Penney's  help  desk  function.  Help  desk  technicians  answered  calls  and  determined,  in 
most  cases,  who  could  address  them.  Only  occasionally  did  they  solve  the  problems  themselves. 
Some  firms  choose  to  put  more  technically  competent  individuals  on  the  help  desk.  Note  that  JCP 
chose  to  use  the  help  desk  as  an  entry  level  position.  The  help  desk  was  as  much  a  training  ground 
for  IT  staff  as  it  was  a  service  to  Penney's  internal  IT  customers.  The  InfoSys  database  helped 
accumulate  the  learning  that  was  possible  from  help  desk  calls. 

Network  Management:  Network  management  has  become  particularly  challenging  and  important  due 
to  the  growth  of  distributed  computing.  While  computing  tasks  are  often  completed  on  the  desktop, 
many,  if  not  most,  require  access  to  a  network.  When  the  network  is  down,  individuals  often  find 
themselves  unable  to  complete  their  work.  In  some  industries  such  as  financial  services,  catalog 
sales,  and  transportation,  business  nearly  grinds  to  a  standstill  if  the  network  goes  down.  Network 
failures  of  a  significant  amount  of  time  can  cost  firms  millions  of  dollars  in  revenues.  Thus,  network 
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management  is  critical.  It  involves  monitoring  all  the  networks  as  well  as  all  the  devices  connected 
to  the  network.  As  noted  in  the  case,  it  is  easy  to  observe  when  a  network  and/or  devices  on  that 
network  fails,  but  usually  one  failure  impacts  neighboring  devices.  Current  monitoring  technologies 
are  usually  not  sophisticated  enough  to  isolate  the  source  of  a  problem.  This  is  why  John  Dratch  is 
struggling  to  decide  what  to  do  when  the  source  of  a  failure  is  unclear.  He  can  send  out  multiple 
alerts  and  put  too  much  manpower  on  a  problem  or  send  out  no  alerts  and  wait  until  a  customer  calls 
to  complain. 

II.  Network  and  Systems  Management  at  JCPenney 

The  second  part  of  the  class  discussion  can  focus  on  Penney's  decision  to  centralize  essentially  all 
aspects  of  the  systems  and  network  management  function.  Students  should  observe  that  this  is  a  very 
neat  architecture  —  everything  comes  back  to  the  center.  It  is  a  simple  architecture  to  articulate  but 
requires  a  great  deal  of  will  and,  in  most  cases,  a  centralized  organizational  culture  to  enable  it.  JCP 
has  eight  business  units  but  operations  are  dominated  by  the  1250  stores.  Thus,  it  feels  very  much 
like  a  centralized  business.  Philosophically,  it  is  reasonably  easy  to  argue  that  JCP  should  organize 
its  computer  operations  centrally.  Not  all  firms  are  comfortable  with  this  organizational  design, 
despite  the  fact  that  it  is  likely  to  be  the  most  cost  effective  way  to  manage  computer  operations. 
Where  different  business  units  have  few  synergies,  however,  centralizing  computer  operations  has 
significant  disadvantages. 

Many  firms  keep  help  desks  at  local  sites  so  that  help  desk  technicians  can  provide  hands-on  support 
for  their  clients.  Some  have  more  distributed  change  control  processes,  which  rely  more  on  the 
cooperation  of  operations'  managers  at  remote  sites.  JCP  had  the  option  to  take  a  less  centralized 
approach,  but  the  centralized  unit  made  sense  given  organizational  structure  and  processes. 

It  is  worth  noting  that  JCP  invested  significant  resources  into  infrastructure  management.  It  is  also 
worth  noting  that  several  unique  characteristics  about  the  firm  made  this  possible:  centralized 
operations  environment,  top  management  commitment  to  IT  and  its  management,  very  competent 
IT  managers,  years  of  experience  with  a  disciplined  approach  to  IT  operations  while  still  in  a 
mainframe  environment,  strong  financial  position  as  a  firm  with  sufficient  resources  allocated  to  IT. 
Firms  with  fewer  resources  or  less  commitment  on  the  part  of  senior  management  may  not  be  as 
successful  in  generating  funding  for  initiatives  targeted  at  reducing  the  cost  of  systems  operations. 


III.  The  ITCC  at  JCPenney 

The  ITCC  is  the  key  component  of  JCP's  operations  management  architecture.  A  number  of  critical 
success  factors  make  it  a  success.  First,  Penney's  commitment  to  the  concept  resulted  in  a  state-of- 
the-art  facility,  which  likely  provides  a  satisfying  work  environment.  Although  the  room  can  be 
somewhat  dark  (for  purposes  of  more  easily  viewing  the  screens  of  data  in  the  front  of  the  room), 
it  is  an  impressive  and  comfortable  looking  room. 

A  great  deal  of  attention  has  been  paid  to  the  needs  of  ITCC  employees.  Career  paths  and 
opportunities  for  advancement  have  been  clearly  enumerated.  Three-day  and  four-day  twelve-hour 
shifts  (rather  than  five  eight-hour  shifts)  appeal  to  many  of  the  workers,  who  appreciate  both  the 
predictability  and  the  flexibility  of  having  a  short  work  week.  Finally,  the  technology  support  and 


organizational  processes  supporting  the  worlcers  make  it  possible  for  the  employees  to  feel 
competent  in  their  work.  The  technologies  help  train  them  even  as  they  walk  them  through  their  jobs. 

Another  aspect  of  the  ITCC  that  has  contributed  to  its  success  are  the  efforts  towards  continuous 
improvement.  Incident  report  tracking  clarifies  performance  goals  for  the  associates  and  alerts 
management  to  potential  problems.  It  identifies  needs  for  new  systems  or  for  associate  training. 
These  clear  goals  help  focus  both  management  and  associate  efforts  to  provide  high  quality  support 
for  JCP  systems. 

IV.  Investment  in  ITCC  Technology  Support 

Unlike  external  customer-oriented  systems  support,  investments  in  infrastructure  management 
technologies  require  a  return  on  investment  that  is  usually  based  on  cost  reductions.  The  calculations 
of  the  return  on  such  an  investment  are  straightforward  ROI  or  payback  analyses.  It  can  be  difficult, 
however,  to  identify,  in  advance,  what  a  system  will  cost  to  develop  or  install.  It  is  also  difficult  to 
anticipate  actual  head  count  reductions  or  reduced  systems  failures.  Penney' s  experience  in  both  its 
prior  management  environment  and  with  the  ITCC  help  with  those  estimates.  Even  with  top 
management  support,  JCP  invests  sparingly  in  new  technologies  for  the  ITCC. 

V.  Conclusion  —  Transferability  of  the  JCP  model 

Class  discussion  might  close  by  considering  all  the  factors  that  must  be  in  place  in  order  to  have 
really  effective  network  and  systems  management  in  a  firm.  Clearly,  technically  competent  staff  are 
a  prerequisite  as  are  effective  project  managers  who  can  develop  and  implement  the  technology 
support  needed  to  make  it  happen.  Competent  staff  must  have  the  confidence  of  business 
management  in  order  to  secure  the  funding  to  invest  in  infrastructure  and  operations  support 
technologies.  Note  the  role  of  the  customer  service  representatives  in  sustaining  that  trust  and 
confidence.  Finally,  the  firm  needs  a  clear  vision  of  how  operations  will  be  managed.  Many  firms 
lack  a  well-articulated  vision  for  how  IT  operations  will  be  managed.  Responsibility  for  the  key 
network  and  systems  management  functions  must  be  assigned,  and  processes  for  carrying  out  those 
responsibilities  must  be  clearly  communicated  and  enforced.  The  JCP  architecture  should  not  be 
viewed  as  the  appropriate  approach  for  every  firm,  but  its  clear  vision  and  focused  efforts  for 
fulfilling  that  vision  serve  as  a  useful  model. 


( 


Is  1  12    08 


Date  Due 


Lib-26-67 


MIT  LIBRARIES 


3  9080  01428  0652 


